Software applications are used in the medical field, in particular in the field of (digital) medical imaging, for creating, modifying, archiving and transmitting between different nodes of a medical network medical data, such as, for example, digital examination images, patient data, results reports, etc. A medical network refers here to an ensemble of devices that are interconnected for data exchange for medical imaging purposes. The devices of such a medical network comprise in particular medical modalities, results computers, servers, databases and other data processing systems. In particular a medical network refers to a so-called DICOM network in which the devices (DICOM nodes) communicate with one another on the basis of the DICOM standard. In this context an image-generating medical examination device, in particular a computer tomograph, magnetic resonance tomograph, ultrasound scanner, etc., is referred to as a modality or image source.
A discrete functional/thematic field such as medical imaging—also referred to as “domain” in software development—requires specially adapted software solutions. Particularly in the domain of medical imaging, owing to the size of current medical equipment, the variety of tasks to be performed and the increasing electronic internetworking of different medical subfields, the domain-specific software applications designed for this purpose are highly complex and are becoming increasingly more so.
The creation of such a software application requires a high level of programming knowledge and experience from a developer. To date software applications for the medical imaging domain have been almost exclusively monolithic, that is to say have been created as one application block. In the event of changes being required, for a software update for example, such an application block must always be changed in its entirety. As a consequence, a huge amount of work is required for the creation of the application and its maintenance, which consequently hinders its timely further development. Moreover, a monolithic software application is usually relatively prone to error.
On the one hand software applications for medical imaging usually have a complex software architecture with several layers. On the other hand, the functions and services of such a software application are divided into a number of functional subgroups, referred to as subdomains below. Of prime importance for the medical imaging field in particular are the subdomains of data management, (data) transfer, worklist management, image processing, volume processing, reporting and image capture or examination.
The subdomain of “data management” comprises all the functionality of a congeneric software application relating to data access, in particular fundamental functions such as reading data from a file system, writing data into such a file system, and deleting stored data as well as creating files. The “file system” refers here to a structure in which data is stored in the form of files and which forms an ordering and access system for this data. A file system may correspond here to a physical storage medium, for example a hard disk, CD-ROM, etc., or it may be designed as a purely logical structure, for example as a virtual drive. The term data management furthermore comprises functionality built on top of this, in particular functions for searching and identifying specific data, access controls to the stored data, and local caching of data. Owing to the special nature of the data processed in the medical imaging field, in particular medical image data which is characterized by a very high memory requirement and close content links between image information and the associated textual information, so-called metadata, the data management employed in the medical imaging field is also subject to domain-specific requirements. Since the data in modern medical imaging is usually processed by a multiplicity of users at a large number of nodes of a computer network, effective data management is crucially important in this field in order to ensure the reliable and effective functioning of a software application designed for this field. The term data management is abbreviated to “DM” below.
The subdomain of (data) “transfer” (abbreviated to “TF” below) comprises all the functionality of a congeneric software application designed for the transmission of data, in particular medical image, volume, text and workflow data, between two devices or file systems of a medical network, for example in the context of the DICOM standard.
The subdomain of “worklist (management)” (abbreviated to “WL” below) comprises all the functionality of a congeneric software application designed for the creation and control of so-called worklists. In particular, such worklists are used in the medical imaging field for assigning steps of a medical workflow organized in a shared manner to the individual nodes of the medical network and for the automated coordination of the execution of the workflow. Such worklists are standardized in particular in the DICOM standard for the medical imaging field.
The subdomain of “image processing” (abbreviated to “IP” below) comprises all the functionality of a congeneric software application designed for modifying and displaying (two-dimensional) medical image data, comprising for example contrast and brightness operations as well as other color change operations, smoothing, sharpening or other filters, 2D pattern recognition (segmenting), etc.
The subdomain of “volume processing” (abbreviated to “VOL” below) covers all the functionality of a congeneric software application designed for creating multi-dimensional structures (3D/4D/ . . . scenes) on the basis of medical image data as well as handling, processing and displaying such structures or their two-dimensional steps and projections. Volume processing comprises in particular the visual/spatial representation of three-dimensional structures (volume rendering), 3D animation, and the generation of sectional images etc. In the text below “volume data” refers to data that contains image or structure information depending on a coordinate system having more than two dimensions. In contrast, “image data” is used to refer only to data containing two-dimensional image or structure information. In addition to customary images, image data here also refers in the wider sense to other data of a two-dimensional nature, in particular measurement curves such as so-called waveforms or spectral data for example. The distinction between image data and volume data is important insofar as, in contrast to volume data, image data can be represented directly on a screen or printout, and consequently is subject to quite different requirements in relation to the respective data processing.
The subdomain of “reporting” (abbreviated to “REP” below) comprises all the functionality of a congeneric software application that supports the creation of medical reports, in particular results reports and presentations, in particular using structured data (e.g. according to the DICOM or HL7 standard).
Finally, the subdomain of “image capture” or “examination” (abbreviated to “EXAM” below) comprises all the functionality of a congeneric software application designed for creating medical image data, that is to say for generating images of examination results on the image-generating modality, including real-time (live) display of the image data captured as well as other services that support image recording.
In conventional applications for the medical imaging domain, the components of an application layer usually depend in a complex manner both on components in the same layer and on components of other layers, with in particular frequently different subdomains being linked permanently to one another as a result of such dependencies. This hinders the further development of software applications, particularly since the mesh of interdependencies means that a change in one component usually results in a cascade of changes. The further development of such a software application is also highly prone to error, particularly since any dependency overlooked on making a change can greatly impair the stability of the software application.
To simplify application development, so-called frameworks exist as support environments for an application developer. A framework often encapsulates the individual layers of a software application within a generic runtime environment and consequently enables the application to be executed independently of the platform and/or the location of execution.
One important framework is the .NET framework from Microsoft Corporation. This framework enables a wide variety of programming languages such as C#, Visual Basic.NET, C++/CLI or JScript.NET to be used as the basis for programming an n-layered application. Irrespective of the type of programming language used, the application and/or respective architecture layer of the application is converted into an “intermediate language” (“Common Intermediate Language” (abbreviated CIL), previously also known as “Microsoft Intermediate Language” (abbreviated MSIL)).
The application programming interfaces (abbreviated to API) that are required between the individual layers of the application are very important here. A distinction is drawn between function-oriented, interface-oriented and protocol-oriented application programming interfaces. In contrast to function-oriented and interface-oriented application programming interfaces, protocol-oriented application programming interfaces are not dependent on the operating system of the platform and the type of application layers to be connected.